Globally, the amount of data exchanged electronically is staggering. For example, by some estimates, over 100 billion business emails are exchanged per day, 50 billion mobile instant messages are exchanged per day, and 8.6 trillion text messages are sent each year. Although much of the exchanged information is legitimate, useful, or at least benign, a great deal of electronic communications contains undesirable, and even malicious, content. Indeed, the vast majority of all transmitted emails are spam. In addition, mobile message spam, e.g., text message spam, is on the rise. As a result of this onslaught of unwanted communication, measures to filter undesirable messages and message content are constantly being developed and refined. Thus, those who generate undesirable messages and message content and those who filter undesirable content are in a constantly evolving arms race.
One means by which undesirable messages and message content is filtered or blocked is by identifying those messages that provide sender address data, e.g. data populating a “From” field that includes data identifying a server, e.g., a web-host domain, that differs from the server/domain from which the message was actually sent. This type of filtering is relatively effective given that many spam messages do indeed include a “From” address that identifies a server/domain that differs from the server/domain from which the message was actually being sent in an effort to hide the source and otherwise mislead the recipient. However, an unintended consequence of this blocking or filtering scheme is that many legitimate messages sent through intermediary services on behalf of users are also blocked.
To understand how this unintended result comes about, it is necessary to first understand how misdirected responses such as notification of delivery anomaly events, e.g. delivery failure events, and misdirected replies are generated and processed. In the event that a message, such as, but not limited to, an email message, cannot be delivered to the designated recipient address, notification of the delivery anomaly event, i.e., delivery anomaly event notification data, is transmitted to the sender address associated with the original message, i.e., the address listed in the “From” field of the original message.
Likewise, even if the message is successfully delivered to the intended recipient, the recipient may reply to the message, e.g., generate a reply message, using the sender address data in the “From” field of the message rather than the address data in the “Reply To” field. Therefore, the reply is misdirected to the sender address data rather than to the address data in the “Reply To” field. For the sake of readability, both delivery anomaly event notifications and misdirected replies will be referred to collectively as misdirected responses.
In the discussion above, sending the notification of the delivery anomaly event to the sender address associated with the original message, i.e., the address listed in the “From” field of the original message, is a viable and efficient procedure if the original message is sent by a single party, e.g., a single user. This is because if the sending party and the user needing to receive the notification of the delivery anomaly event are the same party, then the address of the user and the address listed in the “From” field of the message are the same. Likewise, if the original message is sent by a single party, any reply message sent to the “From” field of the original message is likely to be received by the party. Therefore, the reply message is not likely to be misdirected.
However, it is often the case that a given message is sent on behalf of a user by the intermediary service, such as, but not limited to, tax preparation software systems, financial management systems, and small business management software systems. In these instances, the intermediary service has an associated sender address, which includes intermediary service domain identification data. The sender address associated with the intermediary service is typically different from a user routing address, which includes user domain identification data and is used to route messages and notifications directly to the user. Consequently, when a message is generated and sent through an intermediary service, and/or a message delivery system associated with the intermediary service, if the sender address for the actual sender of the message, i.e., the intermediary service or a message delivery system associated with the intermediary service, is used to populate the “From” field, then any notification for notifying users of misdirected response messages will be routed to the intermediary service, or a message delivery system associated with the intermediary service, and not the user on whose behalf the message was generated and sent. Unfortunately, the user is the party that most likely needs to be notified of any misdirected response directly and as soon as possible so that appropriate action can be taken.
This is a significant problem for both the users of the intermediary services and providers of the intermediary services because while generating and delivering messages for users is an important feature of many intermediary services, those intermediary services are not currently capable of efficiently forwarding notifications of misdirected responses to users in a timely manner. Furthermore, these intermediary services do not have the desire to devote the resources currently required to efficiently and effectively forward notifications of misdirected responses. In short, the intermediary services that provide the message delivery systems and domains typically have no association with the messages sent by their individual users. Consequently, the intermediary services are neither particularly concerned with misdirected responses, nor are they in the best position to deal with the process of notifying users of misdirected response messages. Arguably, however, by sending messages on behalf of their users, the intermediary services accept responsibility for ensuring that their users' messages are successfully delivered, or at least that the user is made aware of any misdirected responses. Despite this responsibility, intermediary services are currently forced to accept some amount of loss associated with misdirected responses. This is a real problem because, in theory, there is no acceptable level of loss associated with misdirected responses. Indeed, bounced and misdirected messages can result in important communications being lost, time squandered, and money wasted.
To solve this problem, many intermediary services began using the user routing address, including user domain identification data, associated with the user to populate the “From” field of messages sent on behalf of the user. Consequently, if the message sent on behalf of the user was subject to a misdirected response, the notification of the misdirected response would be sent to the user routing address, including user domain identification data, in the “From” field of the message rather than to the sender address associated with the intermediary service, or a message delivery system associated with the intermediary service.
The solution described above had the potential to solve the problem related to the notification of a misdirected response. As noted, however, currently deployed spam and malware identification and blocking systems filter, or block, messages whose sender address data, e.g. data populating a “From” field, includes data identifying a server/domain that differs from the server/domain from which the message is actually being sent. Consequently, when the user routing address, including user domain identification data, associated with the user is used to populate the “From” field of messages sent on behalf of the user through the intermediary service, or a message delivery system associated with the intermediary service, and the intermediary service, or a message delivery system associated with the intermediary service, is the actual sending entity with a different address including an intermediary service domain identification data different from the user domain identification data, the message is identified as spam/malware, and is blocked or filtered.
As one specific illustrative example, assume the intermediary service is a financial management service that sends messages containing message data representing invoices on behalf of its users. To pass through the filtering mechanisms described above, the financial management service's message delivery system must provide sender address data that identifies the message delivery system server and/or domain provided by, or associated with, the financial management service. In other words, the sender address data used to populate the “From” field of the message must identify a domain that matches the domain of the financial management service's message delivery system. Therefore, the sender address of the financial management service's message delivery system must be used to populate the “From” field. However, this means that when the financial management service's message delivery system attempts to deliver an invoice on behalf of one of its users but delivery of the message including the invoice fails or some other delivery anomaly event occurs, notification of the delivery anomaly event will be directed to the financial management service's message delivery system server and/or domain rather than the user who wished to send the invoice. Similarly, if the intended recipient of the message and invoice attempts to reply to the message using the sender address data in the “From” field rather than the address in the “Reply To” field, the reply message will be misdirected to the financial management service's server and/or domain rather than to the user who is the actual intended recipient. In both these scenarios, the user would remain ignorant of the delivery anomaly event, misdirected reply, or any other response directed to the sender address.
As discussed above, despite numerous historical efforts to solve it, the long standing problem of ensuring that notification of misdirected responses sent to the “From” field associated with messages sent by an intermediary service on behalf of a user are routed to the user remains a significant issue for both users of intermediary services and providers of intermediary services.
What is needed is a solution to the long standing problem of intermediary service users not receiving notification of misdirected responses associated with messages sent on their behalf by an intermediary service.